AWS AmazonCloudWatch documentation change
Summary
Reorganized documentation structure, added Application Signals configuration details, and moved troubleshooting section. Introduced Auto Monitor feature for Application Signals with configuration examples.
Security assessment
The changes primarily focus on feature enhancements (Application Signals Auto Monitor) and documentation reorganization. While the Auto Monitor feature involves automatic instrumentation of applications, there's no explicit mention of addressing security vulnerabilities or adding security controls. The documentation emphasizes monitoring configuration rather than security hardening.
Diff
diff --git a/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.md b/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.md index a5aa00d65..0caa8f6d7 100644 --- a//AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.md +++ b//AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.md @@ -5 +5 @@ -Option 1: Install using EKS Pod Identity Option 2: Install with IAM permissions on worker nodes Option 3: Install using IAM service account role (applies only to using the add-on)Considerations for Amazon EKS Hybrid Nodes(Optional) Additional configurationTroubleshootingCollect Java Management Extensions (JMX) metricsEnable Kueue metricsAppending OpenTelemetry collector configuration files +Option 1: Install using EKS Pod Identity Option 2: Install with IAM permissions on worker nodes Option 3: Install using IAM service account role (applies only to using the add-on)Considerations for Amazon EKS Hybrid Nodes(Optional) Additional configurationCollect Java Management Extensions (JMX) metricsEnable Kueue metricsAppending OpenTelemetry collector configuration filesApplication Signals configurationTroubleshooting @@ -27,0 +28,25 @@ When you install the add-on or the Helm chart, you must also grant IAM permissio +###### Topics + + * Option 1: Install using EKS Pod Identity + + * Option 2: Install with IAM permissions on worker nodes + + * Option 3: Install using IAM service account role (applies only to using the add-on) + + * Considerations for Amazon EKS Hybrid Nodes + + * (Optional) Additional configuration + + * Collect Java Management Extensions (JMX) metrics + + * Enable Kueue metrics + + * Appending OpenTelemetry collector configuration files + + * Configuring Application Signals for your Amazon EKS cluster + + * Troubleshooting the Amazon CloudWatch Observability EKS add-on or the Helm chart + + + + @@ -668,47 +692,0 @@ If you want to collect Amazon EBS volume IDs in the performance logs, you must a -## Troubleshooting the Amazon CloudWatch Observability EKS add-on or the Helm chart - -Use the following information to help troubleshoot problems with the Amazon CloudWatch Observability EKS add-on or the Helm chart - -###### Topics - - * Updating and deleting the Amazon CloudWatch Observability EKS add-on or the Helm chart - - * Verify the version of the CloudWatch agent used by the Amazon CloudWatch Observability EKS add-on or the Helm chart - - * Handling a ConfigurationConflict when managing the add-on or the Helm chart - - - - -### Updating and deleting the Amazon CloudWatch Observability EKS add-on or the Helm chart - -For instructions about updating or deleting the Amazon CloudWatch Observability EKS add-on, see [Managing Amazon EKS add-ons](https://docs.aws.amazon.com/eks/latest/userguide/managing-add-ons.html). Use `amazon-cloudwatch-observability` as the name of the add-on. - -To delete the Helm chart in a cluster, enter the following command. - - - helm delete amazon-cloudwatch-observability -n amazon-cloudwatch --wait - -### Verify the version of the CloudWatch agent used by the Amazon CloudWatch Observability EKS add-on or the Helm chart - -The Amazon CloudWatch Observability EKS add-on and the Helm chart installs a custom resource of kind `AmazonCloudWatchAgent` that controls the behavior of the CloudWatch agent daemonset on the cluster, including the version of the CloudWatch agent being used. You can get a list of all the `AmazonCloudWatchAgent` custom resources installed on your cluster u by entering the following command: - - - kubectl get amazoncloudwatchagent -A - -In the output of this command, you should be able to check the version of the CloudWatch agent. Alternatively, you can also describe the `amazoncloudwatchagent` resource or one of the `cloudwatch-agent-*` pods running on your cluster to inspect the image being used. - -### Handling a ConfigurationConflict when managing the add-on or the Helm chart - -When you install or update the Amazon CloudWatch Observability EKS add-on or the Helm chart, if you notice a failure caused by existing resources, it is likely because you already have the CloudWatch agent and its associated components such as the ServiceAccount, the ClusterRole and the ClusterRoleBinding installed on the cluster. - -The error displayed by the add-on will include `Conflicts found when trying to apply. Will not continue due to resolve conflicts mode`, - -The error displayed by the Helm chart will be similar to `Error: INSTALLATION FAILED: Unable to continue with install and invalid ownership metadata.`. - -When the add-on or the Helm chart tries to install the CloudWatch agent and its associated components, if it detects any change in the contents, it by default fails the installation or update to avoid overwriting the state of the resources on the cluster. - -If you are trying to onboard to the Amazon CloudWatch Observability EKS add-on and you see this failure, we recommend deleting an existing CloudWatch agent setup that you had previously installed on the cluster and then installing the EKS add-on or Helm chart. Be sure to back up any customizations you might have made to the original CloudWatch agent setup such as a custom agent configuration, and provide these to the add-on or Helm chart when you next install or update it. If you had previously installed the CloudWatch agent for onboarding to Container Insights, see [Deleting the CloudWatch agent and Fluent Bit for Container Insights](./ContainerInsights-delete-agent.html) for more information. - -Alternatively, the add-on supports a conflict resolution configuration option that has the capability to specify `OVERWRITE`. You can use this option to proceed with installing or updating the add-on by overwriting the conflicts on the cluster. If you are using the Amazon EKS console, you'll find the **Conflict resolution method** when you choose the **Optional configuration settings** when you create or update the add-on. If you are using the AWS CLI, you can supply the `--resolve-conflicts OVERWRITE` to your command to create or update the add-on. - @@ -917,0 +896,161 @@ or +## Configuring Application Signals for your Amazon EKS cluster + +[Application Signals](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html) is enabled by default when installing either the CloudWatch Observability EKS add-on or the Helm chart. You can further customize specific settings using the advanced configuration for the Amazon EKS add-on or by overriding values with the Helm chart. + +**Application Signals Auto monitor** + +Version 4.0.0 of the CloudWatch Observability Amazon EKS add-on and Helm chart introduces new functionality. You can now automatically enable Application Signals for all or specific service workloads in your EKS cluster through the Auto monitor configuration. The following `autoMonitor` settings can be specified within the `applicationSignals` section under the `manager` section of the advanced configuration. + + * _monitorAllServices_ – A boolean flag to enable (true) or disable (false) monitoring of all service workloads by Auto monitor. Defaults to false. Enabling this flag will ensure that all Kubernetes workloads (Deployments, DaemonSets, and StatefulSets) in the cluster that are mapped to a Kubernetes Service will be in scope for automatic enablement of Application Signals when they are brought up for the first time (or when restarted for existing workloads). The system excludes workloads in the `kube-system` and `amazon-cloudwatch` namespaces by default. + + * _languages_ – A list of strings specifying the set of languages that Application Signals will try to automatically instrument your services with, when `monitorAllServices` is enabled. Defaults to all the [supported languages](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html). + + * _restartPods_ – A boolean flag controls whether workloads restart after configuration changes. Defaults to false. Enabling this flag to `true` controls whether Kubernetes workloads within Auto monitor scope restart automatically when saving configuration changes. Any settings on your Kubernetes workloads that influence the restart of the pods such as `updateStrategy` will be considered. Consider that restarting may cause service downtime. + + * _customSelector_ – Settings to select specific Kubernetes namespaces or workloads for Auto monitor. + + * _java_ – Specify workloads to automatically instrument with Java + + * _python_ – Specify workloads to automatically instrument with Python + + * _nodejs_ – Specify workloads to automatically instrument with Node.js + + * _dotnet_ – Specify workloads to automatically instrument with .NET + +For each of the languages above, the following fields can be configured. + + * _namespaces_ – A list of strings specifying the namespaces to be selected. Defaults to an empty list, that is [] + + * _deployments_ – A list of strings specifying the deployments to be selected. Specify in `namespace/deployment`format. Defaults to an empty list, that is [] + + * _daemonsets_ – A list of strings specifying the daemonsets to be selected. Specify in `namespace/daemonset` format. Defaults to an empty list, that is [] + + * _statefulsets_ – A list of strings specifying the statefulsets to be selected. Specify in `namespace/statefulset` format. Defaults to an empty list, that is [] + + * _exclude_ – Settings to exclude specific Kubernetes namespaces or workloads from Auto monitor. Excluding a workload takes precedence when the same workload is also within scope of `monitorAllServices` or `customSelector`. + + * _java_ – Specify workloads to exclude from being automatically instrumented with Java + + * _python_ – Specify workloads to exclude from being automatically instrumented with Python + + * _nodejs_ – Specify workloads to exclude from being automatically instrumented with Node.js + + * _dotnet_ – Specify workloads to exclude from being automatically instrumented with .NET + +For each of the languages above, the following fields can be configured. + + * _namespaces_ – A list of strings specifying the namespaces to be excluded. Defaults to an empty list, that is [] + + * _deployments_ – A list of strings specifying the deployments to be excluded. Specify in `namespace/deployment`format. Defaults to an empty list, that is [] + + * _daemonsets_ – A list of strings specifying the daemonsets to be excluded. Specify in `namespace/daemonset` format. Defaults to an empty list, that is [] + + * _statefulsets_ – A list of strings specifying the statefulsets to be excluded. Specify in `namespace/statefulset` format. Defaults to an empty list, that is [] + + + + +The following is an example configuration that automatically enables Application Signals for all existing and new service workloads on the cluster. + + + manager: + applicationSignals: + autoMonitor: + monitorAllServices: true + restartPods: true + +The following is an example configuration that automatically enables Application Signals for any new service workload that is brought up and for any existing service workload that is explicitly restarted on the cluster. + + + manager: + applicationSignals: + autoMonitor: + monitorAllServices: true + +The following is an example configuration that automatically enables Application Signals with Java for all existing and new pods corresponding to a workload in the `pet-warehouse` namespace. + + + manager: + applicationSignals: + autoMonitor: + restartPods: true + customSelector: + java: + namespaces: ["pet-warehouse"] + +The following is an example configuration that automatically enables Application Signals with Python for all existing and new service workloads in the cluster excluding the `pet-clinic` deployment. + + + manager: + applicationSignals: + autoMonitor: + monitorAllServices: true + languages: ["python"] + restartPods: true + exclude: + python: + deployments: ["pet-warehouse/pet-clinic"] + +The following is an example configuration that automatically enables Application Signals with Java for all service workloads in the cluster except for the ones in the `python-apps` namespace and further enables Application Signals with Python specifically for the `sample-python-app` deployment in the `python-apps` namespace. + + + manager: + applicationSignals: + autoMonitor: + monitorAllServices: true + languages: ["java"] + restartPods: true + customSelector: + python: + deployments: ["python-apps/sample-python-app"] + exclude: + java: + namespaces: ["python-apps"] + +## Troubleshooting the Amazon CloudWatch Observability EKS add-on or the Helm chart + +Use the following information to help troubleshoot problems with the Amazon CloudWatch Observability EKS add-on or the Helm chart +