Merge pull request #489 from vasireddy99/fixlink

[Chore]- Updating docs and corrected links

Author: vasireddy99

src/docs/components/ecs-metrics-receiver.mdx

@@ -1,5 +1,5 @@
 ---
-title: 'Getting started using AWS ECS container metrics receiver in AWS OpenTelemetry Collector'
+title: 'Getting started using AWS ECS container metrics receiver in AWS Distro for OpenTelemetry Collector'
 description:
     The Amazon ECS container agent provides a method to retrieve various task metadata and Docker stats, which is
     referred to as the task metadata endpoint. AWS Container Observability team wrote a receiver in the OpenTelemetry

src/docs/getting-started/adot-eks-add-on/requirements.mdx

@@ -12,9 +12,9 @@ path: '/docs/getting-started/adot-eks-add-on/requirements'
 
 * [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html) is installed
 
-* Your cluster should be on Kubernetes version 1.19 or higher. You can verify the version you’re running with the following command:
+* Your cluster should be on Kubernetes version 1.21 or higher. You can verify the version you’re running with the following command:
 ```console
-kubectl version | grep "Server Version"`
+kubectl version | grep "Server Version"
 ```
 
 * Make sure that you can use kubectl with your EKS cluster by updating your `kubeconfig` if necessary:

src/docs/getting-started/container-insights.mdx

@@ -36,7 +36,7 @@ The following platforms are supported:
 
 - <Link to="/docs/getting-started/container-insights/eks-infra">Amazon EKS and Kubernetes platforms on Amazon EC2</Link>
 - <Link to="/docs/getting-started/container-insights/eks-fargate">Amazon EKS and Kubernetes platforms on Amazon Fargate</Link>
-- [Amazon ECS with cluster- and service-level metrics](https://aws-otel.github.io/docs/components/ecs-metrics-receiver)
+- [Amazon ECS with cluster and service-level metrics](https://aws-otel.github.io/docs/components/ecs-metrics-receiver)
 - Amazon ECS on Amazon EC2 with instance-level metrics (upcoming)
 
 ## Collecting Prometheus metrics

src/docs/getting-started/container-insights/ecs-prometheus.mdx

@@ -14,7 +14,6 @@ import ecssdviewmertric from "assets/img/docs/gettingStarted/container-insights/
     GettingStarted / <Link to="/docs/getting-started/container-insights">Container Insights</Link> / <Link to="/docs/getting-started/container-insights#collecting-prometheus-metrics">Container Insights for Prometheus Support</Link>
 </p>
 
-
 ## Overview
 
 To collect Prometheus metrics from tasks running on ECS and send it to CloudWatch using AWS Distro for OpenTelemetry Collector (ADOT).

src/docs/getting-started/container-insights/eks-fargate.mdx

@@ -10,10 +10,6 @@ import logEventImg from "assets/img/docs/gettingStarted/container-insights/ADOT-
 import ADOTMetricsImg from "assets/img/docs/gettingStarted/container-insights/ADOT-metrics.png"
 import performanceImg from "assets/img/docs/gettingStarted/container-insights/ADOT-performance.png"
 
-<p>
-    GettingStarted / <Link to="/docs/getting-started/container-insights">Container Insights</Link> / <Link to="/docs/getting-started/container-insights#collecting-fargate-metrics">Container Insights for EKS Fargate</Link>
-</p>
-
 This section shows the design of components in an ADOT Collector pipeline that enables the collection of Container Insights metrics from EKS Fargate workloads and explains how to configure and deploy an ADOT Collector to collect system metrics from workloads deployed to an EKS Fargate cluster and send them to CloudWatch.
 
 ## Design of Container Insights support in ADOT Collector for EKS Fargate
@@ -55,7 +51,7 @@ Let’s get into the details of deploying the ADOT Collector in an EKS Fargate c
 
 1. List of pre-requisites for deploying the ADOT Collector.
 
-* An EKS cluster that supports Kubernetes version 1.18 or higher. You may create the EKS cluster using one of the [approaches outlined here](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html).
+* An EKS cluster that supports Kubernetes version 1.21 or higher. You may create the EKS cluster using one of the [approaches outlined here](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html).
 * When your cluster creates pods on AWS Fargate, the components that run on the Fargate infrastructure must make calls to AWS APIs on your behalf. This is so that they can execute actions such as pull container images from Amazon ECR. The [EKS pod execution role](https://docs.aws.amazon.com/eks/latest/userguide/pod-execution-role.html) provides the IAM permissions to do this. Create a Fargate pod execution role as [outlined here](https://docs.aws.amazon.com/eks/latest/userguide/fargate-getting-started.html#fargate-sg-pod-execution-role).
 * Before you can schedule pods running on Fargate, you must define a [Fargate profile](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html) that specifies which pods should use Fargate when they are launched. For the sample deployments used here, we create two Fargate profiles as [outlined here](https://docs.aws.amazon.com/eks/latest/userguide/fargate-getting-started.html#fargate-gs-create-profile).  The first Fargate profile is named fargate-container-insights, specifying the namespace fargate-container-insights. The second one is named applications, specifying the namespace golang.
 * The ADOT Collector requires IAM permissions to send performance log events to CloudWatch. This is done by associating a Kubernetes service account with an IAM role using the [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) feature supported by EKS. The IAM role should be associated with the AWS managed policy `CloudWatchAgentServerPolicy`. The helper script shown below may be used, after substituting the CLUSTER_NAME and REGION variables, to create an IAM role named `EKS-ADOT-ServiceAccount-Role` that is granted these permissions and is associated with a Kubernetes service account named `adot-collector`.

src/docs/getting-started/container-insights/eks-prometheus.mdx

@@ -8,10 +8,6 @@ import dashboardImg from "assets/img/docs/gettingStarted/container-insights/eks-
 import logsImg from "assets/img/docs/gettingStarted/container-insights/eks-prometheus-logs.png"
 import metricsImg from "assets/img/docs/gettingStarted/container-insights/eks-prometheus-metrics.png"
 
-<p>
-    GettingStarted / <Link to="/docs/getting-started/container-insights">Container Insights</Link> / <Link to="/docs/getting-started/container-insights#collecting-prometheus-metrics">Container Insights for Prometheus Support</Link>
-</p>
-
 This section explains how to set up Prometheus monitoring with the ADOT Collector in a cluster running Amazon EKS or Kubernetes. With [default configurations](https://github.com/aws-observability/aws-otel-collector/tree/main/config/eks/prometheus), the ADOT Collector automatically scrapes and imports metrics for the following workloads running in a cluster.
 * [AppMesh](https://github.com/aws-observability/aws-otel-collector/blob/main/docs/developers/container-insights-eks-app-mesh.md#install-app-mesh-and-sample-applications)
 * [HAProxy](https://github.com/aws-observability/aws-otel-collector/blob/main/docs/developers/container-insights-eks-haproxy.md#install-haproxy)

src/docs/getting-started/lambda/lambda-java-auto-instr.mdx

@@ -120,14 +120,13 @@ To disable OpenTelemetry for your Lambda function, remove the Lambda layer, remo
 
 ## Configuration
 
-The ADOT Java Auto-instrumentation Agent layer combines both OpenTelemetry Auto Agent and the ADOT Collector.
-The configuration of the ADOT Collector follows the OpenTelemetry standard.
+The ADOT Java Auto-instrumentation Agent layer combines both OpenTelemetry Auto Agent and the ADOT Collector. The configuration of the ADOT Collector follows the OpenTelemetry standard.
 
 By default, the ADOT Lambda layer uses the [config.yaml](https://github.com/aws-observability/aws-otel-lambda/blob/main/adot/collector/config.yaml), which exports telemetry data to AWS X-Ray. To customize the Collector config, see the [main Lambda section for custom configuration instructions](/docs/getting-started/lambda#custom-configuration-for-the-adot-collector-on-lambda).
 
 ## Exporting Metrics to AMP
 
-The layer is not configured by default to export Prometheus metrics, see Amazon Managed Service for Prometheus (AMP)(https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html). To enable it:
+The layer is not configured by default to export Prometheus metrics, see Amazon Managed Service for Prometheus (AMP)[https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html]. To enable it:
 
 1. Upload a custom collector configuration file `collector.yaml` with your Lambda application, like the example shown below, with the `prometheusremotewriteexporter` and the `sigv4authextension` enabled. Set up the `endpoint` of your own AMP workspace, and `region` of the `sigv4authextension`. 
 ```
@@ -166,7 +165,7 @@ Note: If enabling metrics, make sure your Lambda role has the required AWS Prome
 
 ## AMP and AWS Lambda Service Quotas when using the Lambda Layer for Metrics
 
-To learn more about the limits for the number of metrics that can be sent through this Lambda Layer to Amazon Service for Prometheus, refer to the [AMP service quotas](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP_quotas.html). The layer has been tested to output up to the posted service Quotas of AMP without requesting for an increase.  This layer has been tested with the maximum concurrency levels of [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html), of 1000 concurrent invocations, and is able to receive all metrics in AMP. Any higher levels of concurrency or of the posted service quota is not guaranteed. 
+To learn more about the limits for the number of metrics that can be sent through this Lambda Layer to Amazon Service for Prometheus, refer to the [AMP service quotas](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP_quotas.html). The layer has been tested to output up to the posted service Quotas of AMP without requesting for an increase. This layer has been tested with the maximum concurrency levels of [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html), of 1000 concurrent invocations and is able to receive all metrics in AMP. Any higher levels of concurrency or of the posted service quota is not guaranteed.
 
 <SectionSeparator />