CloudWatch 解决方案：Amazon EC2 上的 JVM 工作负载

此解决方案可帮助您使用 CloudWatch 代理，为在 EC2 实例上运行的 JVM 应用程序配置开箱即用的指标收集。此外，它还可以帮助您设置预配置的 CloudWatch 控制面板。有关所有 CloudWatch 可观测性解决方案的一般信息，请参阅 CloudWatch 可观测性解决方案。

要求

此解决方案适用于以下情况：

优势

该解决方案提供 JVM 监测，为以下用例提供宝贵的见解：

以下是该解决方案的主要优点：

下图是此解决方案控制面板的示例。

成本

此解决方案在您的账户中创建和使用资源。您需要为标准使用量付费，包括以下各项：

有关 CloudWatch 定价的信息，请参阅 Amazon CloudWatch 定价。

定价计算器可帮助您估算使用此解决方案的每月大致费用。

此解决方案的 CloudWatch 代理配置

CloudWatch 代理是在您的服务器和容器化环境中持续自主运行的软件。它从您的基础设施和应用程序收集指标、日志和跟踪，并将其发送到 CloudWatch 和 X-Ray。

有关 CloudWatch 代理的更多信息，请参阅使用 CloudWatch 代理收集指标、日志和跟踪信息。

此解决方案中的代理配置收集解决方案的基础指标。可以将 CloudWatch 代理配置为收集比控制面板默认显示更多的 JVM 指标。有关您可以收集的所有 JVM 指标的列表，请参阅 收集 JVM 指标。有关 CloudWatch 代理配置的一般信息，请参阅 CloudWatch 代理收集的指标。

公开 JVM 应用程序的 JMX 端口

CloudWatch 代理依靠 JMX 来收集与 JVM 进程相关的指标。要做到这一点，必须公开 JVM 应用程序的 JMX 端口。公开 JMX 端口的说明取决于您用于 JVM 应用程序的工作负载类型。有关这些说明，请参阅应用程序的文档。

通常，要启用 JMX 端口进行监测和管理，需要为 JVM 应用程序设置以下系统属性。请务必指定未使用的端口号。以下示例设置未经身份验证的 JMX。如果您的安全策略/要求需要使用密码身份验证启用 JMX 或 SSL 进行远程访问，请参阅 JMX 文档以设置所需的属性。

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=port-number
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false

查看应用程序的起始脚本和配置文件，找到添加这些参数的最佳位置。从命令行运行 .jar 文件时，此命令可能如下所示，其中 pet-search.jar 是应用程序 jar 的名称。

$ java -jar -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false pet-search.jar

此解决方案的代理配置

代理收集的指标在代理配置中定义。该解决方案提供代理配置，以收集建议的指标，并为解决方案的控制面板提供合适的维度。

稍后将在为您的解决方案部署代理中介绍部署解决方案的步骤。以下信息旨在帮助您了解如何针对环境自定义代理配置。

您必须针对自己的环境自定义以下代理配置的某些部分：

例如，如果您在同一个账户中运行两个 Java 应用程序，一个用于 order-processing 应用程序，另一个用于 inventory-management 应用程序，则应在每个实例的代理配置中相应地设置 ProcessGroupName 维度。

当您遵循这些准则时，解决方案控制面板将自动根据 ProcessGroupName 维度对指标进行分组。控制面板将包括下拉选项，用于选择和查看特定进程组的指标，从而允许您单独监测各个进程组的性能。

JVM 主机的代理配置

在部署 Java 应用程序的 EC2 实例上使用以下 CloudWatch 代理配置。配置将作为参数存储在 SSM 的 Parameter Store 中，稍后将在步骤 2：在 Systems Manager Parameter Store 中存储建议的 CloudWatch 代理配置文件中详细介绍。

将 ProcessGroupName 替换为进程组的名称。将 port-number 替换为 Java 应用程序的 JMX 端口。如果 JMX 启用了密码身份验证或 SSL 以进行远程访问，请参阅 收集 Java 管理扩展（JMX）指标，了解有关根据需要在代理配置中设置 TLS 或授权的信息。

此配置（在 JMX 区块之外显示的配置）中显示的 EC2 指标仅适用于 Linux 和 macOS 实例。如果您使用的是 Windows 实例，则可以选择在配置中省略这些指标。有关在 Windows 实例上收集的指标的信息，请参阅 Windows Server 实例上的 CloudWatch 代理收集的指标。

{
  "metrics": {
    "namespace": "CWAgent",
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}"
    },
    "metrics_collected": {
      "jmx": [
        {
          "endpoint": "localhost:port-number",
          "jvm": {
            "measurement": [
              "jvm.classes.loaded",
              "jvm.gc.collections.count",
              "jvm.gc.collections.elapsed",
              "jvm.memory.heap.committed",
              "jvm.memory.heap.max",
              "jvm.memory.heap.used",
              "jvm.memory.nonheap.committed",
              "jvm.memory.nonheap.max",
              "jvm.memory.nonheap.used",
              "jvm.threads.count"
            ]
          },
          "append_dimensions": {
            "ProcessGroupName": "ProcessGroupName"
          }
        }
      ],
      "disk": {
        "measurement": [
          "used_percent"
        ]
      },
      "mem": {
        "measurement": [
          "used_percent"
        ]
      },
      "swap": {
        "measurement": [
          "used_percent"
        ]
      },
      "netstat": {
        "measurement": [
          "tcp_established",
          "tcp_time_wait"
        ]
      }
    }
  }
}

为您的解决方案部署代理

安装 CloudWatch 代理有几种方法，具体视用例而定。对于此解决方案，我们建议使用 Systems Manager。它提供了控制台体验，使在单个 AWS 账户中管理一组托管服务器变得更加简单。本节中的说明使用 Systems Manager，适用于没有使用现有配置运行 CloudWatch 代理的情况。您可以按照验证 CloudWatch 代理是否正在运行中的步骤检查 CloudWatch 代理是否正在运行。

如果您已经在部署工作负载的 EC2 主机上运行 CloudWatch 代理并管理代理配置，则可以跳过本节中的说明并按照现有部署机制更新配置。请务必将 JVM 的代理配置与现有的代理配置合并，然后部署合并的配置。如果您使用 Systems Manager 存储和管理 CloudWatch 代理的配置，则可以将配置合并到现有参数值。有关更多信息，请参阅 Managing CloudWatch agent configuration files。

部署过程包括以下步骤：

步骤 1：确保目标 EC2 实例具有所需的 IAM 权限

您必须授予 Systems Manager 安装和配置 CloudWatch 代理的权限。您还必须授予 CloudWatch 代理将遥测数据从 EC2 实例发布到 CloudWatch 的权限。确保附加到实例的 IAM 角色已附加 CloudWatchAgentServerPolicy 和 AmazonSSMManagedInstanceCore IAM 策略。

步骤 2：在 Systems Manager Parameter Store 中存储建议的 CloudWatch 代理配置文件

Parameter Store 通过安全地存储和管理配置参数，简化了 CloudWatch 代理在 EC2 实例上的安装，而无需硬编码值。这可确保更加安全灵活的部署过程，从而实现集中管理，并且可以更轻松地跨多个实例更新配置。

使用以下步骤将建议的 CloudWatch 代理配置文件作为参数存储在 Parameter Store 中。

步骤 3：安装 CloudWatch 代理并使用 AWS CloudFormation 模板应用配置

您可以使用 AWS CloudFormation 安装代理，并将其配置为使用您在前面步骤中创建的 CloudWatch 代理配置。

如果要先编辑模板文件进行自定义，请选择创建堆栈向导下的上传模板文件选项，上传编辑后的模板。有关更多信息，请参阅在 AWS CloudFormation 控制台上创建堆栈。您可以使用以下链接下载模板：https://aws-observability-solutions.s3.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json。

步骤 4：验证代理设置是否正确配置

您可以按照验证 CloudWatch 代理是否正在运行中的步骤验证 CloudWatch 代理是否已安装。如果 CloudWatch 代理尚未安装和运行，请确保已正确设置所有内容。

如果一切设置正确，那么您应该会看到 JVM 指标发布到 CloudWatch。您可以查看 CloudWatch 控制台以验证这些指标是否已发布。

创建 JVM 解决方案控制面板

此解决方案提供的控制面板显示服务器底层 Java 虚拟机（JVM）的指标。它通过聚合和显示所有实例的指标来提供 JVM 的概览，从而提供总体运行状况和运行状态的高级摘要。此外，控制面板还会显示每个指标排名靠前的贡献者（每个指标的前 10 名小部件）明细。这可以帮助您快速识别对观测指标有显著影响的异常值或实例。

解决方案控制面板不显示 EC2 指标。要查看 EC2 指标，您需要使用 EC2 自动控制面板查看 EC2 公开发布的指标，并使用 EC2 控制台控制面板查看 CloudWatch 代理收集的 EC2 指标。有关 AWS 服务自动控制面板的更多信息，请参阅查看单项 AWS 服务的 CloudWatch 控制面板。

要创建控制面板的操作，可以使用以下选项：

通过使用 CloudWatch 控制台创建控制面板，您可以在实际创建和收费之前预览控制面板。

如果要编辑模板文件以出于任何目的对其进行自定义，则可以使用创建堆栈向导下的上传模板文件选项来上传编辑后的模板。有关更多信息，请参阅在 AWS CloudFormation 控制台上创建堆栈。您可以使用以下链接下载模板：https://aws-observability-solutions.s3.amazonaws.com/JVM_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json。

开始使用 JVM 控制面板

您可以使用新的 JVM 控制面板尝试以下几项任务。这些任务允许您验证控制面板是否正常运行，并为您提供使用它来监测 JVM 进程组的一些实践经验。在尝试这些任务的过程中，您将熟悉如何浏览控制面板和解读可视化指标。

选择进程组

使用 JVM 进程组名称下拉列表可选择要监测的进程组。控制面板会自动更新以显示所选进程组的指标。如果您有多个 Java 应用程序或环境，则每个应用程序或环境都可能表示为一个单独的进程组。选择相应的进程组可确保您查看的是要分析的应用程序或环境的特定指标。

查看内存使用情况

从控制面板概览部分中，找到堆内存使用百分比和非堆内存使用百分比小部件。这些小部件显示所选进程组中所有 JVM 使用的堆内存和非堆内存的百分比。百分比高表示可能导致性能问题或 OutOfMemoryError 异常的潜在内存压力。您还可以在按主机分列的内存使用情况下深入查看按主机分列的堆使用情况，以检查使用率较高的主机。

分析已加载的线程和类

在按主机分列的已加载线程和类部分中，找到线程数前 10 名和加载的类前 10 名小部件。查找与其他 JVM 相比，线程或类数量异常多的 JVM。线程过多可能表示线程泄漏或并发量过大，而大量已加载的类可能表明潜在的类加载器泄漏或动态类生成效率低下。

确定垃圾回收问题

在垃圾回收部分，找到以下不同垃圾回收器类型的每分钟垃圾回收调用次数前 10 名和垃圾回收持续时间前 10 名小部件：较新、并发和混合。查找与其他 JVM 相比，回收次数异常多或回收持续时间较长的 JVM。这可能表示存在配置问题或内存泄漏。