设置基于应用的健康检查和自动修复

本文档介绍如何设置基于应用的健康检查，以自动修复托管式实例组 (MIG) 中的虚拟机。此外，还介绍如何执行以下操作：使用健康检查但不使用自动修复、移除健康检查、查看自动修复政策以及检查每个虚拟机的健康状况。

您可以配置基于应用的健康检查来验证虚拟机上的应用是否按预期响应。如果您配置的健康检查检测到虚拟机上的应用没有响应，则 MIG 会将虚拟机标记为健康状况不佳，并对其进行修复。根据基于应用的健康检查修复虚拟机的行为称为自动修复。

您还可以在 MIG 中关闭修复，因此可以使用健康检查而不触发自动修复。

准备工作

设置身份验证（如果尚未设置）。身份验证是通过其进行身份验证以访问 Google Cloud 服务和 API 的过程。如需从本地开发环境运行代码或示例，您可以按如下方式向 Compute Engine 进行身份验证。

Select the tab for how you plan to use the samples on this page:
Console

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
gcloud
1. Install the Google Cloud CLI, then initialize it by running the following command:
  gcloud init
  Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.
2. Set a default region and zone.

价格

设置基于应用的健康检查后，每当虚拟机的健康状况发生变化时，Compute Engine 默认会在 Cloud Logging 中写入日志条目。 Cloud Logging 提供每月免费配额，之后会按数据量计费。为避免产生费用，您可以停用运行状况更改日志。

设置基于应用的健康检查和自动修复

如需在 MIG 中设置基于应用的健康检查和自动修复，必须执行以下操作：

创建健康检查（如果尚未创建）。
在 MIG 中配置自动修复政策以应用健康检查。

创建健康检查

您可以将单个健康检查应用于最多 50 个 MIG。如果您拥有的实例组超过 50 个，请创建多个健康检查。

以下示例展示了如何为自动修复创建健康检查。您可以在 MIG 中为自动修复创建区域级或全球健康检查。在此示例中，您将创建全球健康检查，使其在端口 80 上查找 Web 服务器响应。如需使健康检查探测能够访问 Web 服务器，请配置防火墙规则。

执行此任务所需的权限

您必须拥有以下权限才能执行此任务：

针对项目的 compute.healthChecks.create 权限（如果创建健康检查）。
针对要使用的健康检查的 compute.healthChecks.use 权限。
针对项目的 compute.firewalls.create 权限（如果创建防火墙）。
针对网络的 compute.networks.updatePolicy 权限（如果创建防火墙）。

这些权限是以下预配置角色中的可用权限。

compute.networkAdmin（用于创建健康检查）。
compute.securityAdmin（用于配置防火墙规则以允许健康检查进行连接）。

控制台

为自动修复创建健康检查，这种检查比负载均衡健康检查更加保守。

例如，创建一个查找端口 80 响应的健康检查，该检查可以容许某些失败操作，然后才会将虚拟机标记为 UNHEALTHY，导致其被重新创建。在此示例中，如果健康检查成功返回一次，则会将虚拟机标记为“健康状况良好”。如果健康检查连续失败 3 次，则会将虚拟机标记为”健康状况不佳“。
1. 在 Google Cloud 控制台中，转到创建健康检查页面。
  
  转到“创建健康检查”
2. 为此健康检查指定名称，例如 example-check。
3. 选择一个范围。您可以选择区域级或全球。对于此示例，选择全球。
4. 对于协议，请确保选中 HTTP。
5. 对于端口，请输入 80。
6. 在健康状况判断标准部分中，提供以下值：
  1. 对于检查间隔，请输入 5。
  2. 对于超时，请输入 5。
  3. 设置状况良好判断阈值，指定健康状况不佳的虚拟机必须连续多少次返回成功的健康检查，才能被标记为健康状况良好。对于此示例，请输入 1。
  4. 设置状况不佳判断阈值，指定健康状况良好的虚拟机必须连续多少次返回不成功的健康检查，才能被标记为健康状况不佳。对于此示例，请输入 3。
7. 点击创建以创建健康检查。
创建防火墙规则以允许健康检查探测连接到您的应用。

注意：如果健康检查探测被防火墙规则阻止，则会因无法连接到应用而将您的虚拟机标记为 UNHEALTHY。在这种情况下，健康状况可能良好的虚拟机也会被自动重新创建。
健康检查探测请求来自 130.211.0.0/22 和 35.191.0.0/16 范围内的地址，因此请确保您的网络防火墙规则允许健康检查进行连接。在此示例中，MIG 使用的是 default 网络，并且其虚拟机监听的是端口 80。如果端口 80 尚未在默认网络中打开，请创建防火墙规则。
1. 在 Google Cloud 控制台中，转到防火墙页面。
  
  转到“防火墙政策”
2. 点击创建防火墙规则。
3. 输入防火墙规则的名称。例如 allow-health-check。
4. 对于网络，请选择 default 网络。
5. 对于目标，请选择 All instances in the network。
6. 对于来源过滤条件，请选择 IPv4 ranges。
7. 对于来源 IPv4 范围，输入 130.211.0.0/22 和 35.191.0.0/16。
8. 在协议和端口中，选择指定的协议和端口并执行以下操作：
  1. 选择 TCP。
  2. 在端口字段中，输入 80。
9. 点击创建。

gcloud

为自动修复创建健康检查，这种检查比负载均衡健康检查更加保守。

例如，创建一个查找端口 80 响应的健康检查，该检查可以容许某些失败操作，然后才会将虚拟机标记为 UNHEALTHY，导致其被重新创建。在本示例中，如果虚拟机成功返回一次，则会被标记为“运行状况良好”。如果连续 3 次未能成功返回，则虚拟机会被标记为“运行状况不佳”。以下命令会创建一个全球健康检查。
```
gcloud compute health-checks create http example-check --port 80 \
   --check-interval 30s \
   --healthy-threshold 1 \
   --timeout 10s \
   --unhealthy-threshold 3 \
   --global
```
注意：请使用支持 HTTP、HTTPS、TCP 和 SSL (TLS) 协议的新版健康检查。旧版 Compute Engine HTTP/HTTPS 健康检查继续有效。
创建防火墙规则以允许健康检查探测连接到您的应用。

注意：如果健康检查探测被防火墙规则阻止，则会因无法连接到应用而将您的虚拟机标记为 UNHEALTHY。在这种情况下，健康状况可能良好的虚拟机也会被自动重新创建。

健康检查探测请求来自 130.211.0.0/22 和 35.191.0.0/16 范围内的地址，因此请确保您的防火墙规则允许健康检查进行连接。在此示例中，MIG 使用的是 default 网络，并且其虚拟机监听的是端口 80。如果端口 80 尚未在默认网络中打开，请创建防火墙规则。
```
gcloud compute firewall-rules create allow-health-check \
    --allow tcp:80 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default
```

Terraform

使用 google_compute_http_health_check 资源创建健康检查。

例如，创建一个查找端口 80 响应的健康检查，该检查可以容许某些失败操作，然后才会将虚拟机标记为 UNHEALTHY，导致其被重新创建。在本示例中，如果虚拟机成功返回一次，则会被标记为“运行状况良好”。如果连续 3 次未能成功返回，则虚拟机会被标记为“运行状况不佳”。以下请求会创建一个全球健康检查。
```
resource "google_compute_http_health_check" "default" {
  name                = "example-check"
  timeout_sec         = 10
  check_interval_sec  = 30
  healthy_threshold   = 1
  unhealthy_threshold = 3
  port                = 80
}
```
使用 google_compute_firewall 资源创建防火墙。

注意：如果健康检查探测被防火墙规则阻止，则会因无法连接到应用而将您的虚拟机标记为 UNHEALTHY。在这种情况下，健康状况可能良好的虚拟机也会被自动重新创建。

健康检查探测请求来自 130.211.0.0/22 和 35.191.0.0/16 范围内的地址，因此请确保您的防火墙规则允许健康检查进行连接。在此示例中，MIG 使用的是 default 网络，并且其虚拟机监听的是端口 80。如果端口 80 尚未在默认网络中打开，请创建防火墙规则。
```
resource "google_compute_firewall" "default" {
  name          = "allow-health-check"
  network       = "default"
  source_ranges = ["130.211.0.0/22", "35.191.0.0/16"]
  allow {
    protocol = "tcp"
    ports    = [80]
  }
}
```

如需了解如何应用或移除 Terraform 配置，请参阅基本 Terraform 命令。

REST

为自动修复创建健康检查，这种健康检查比负载均衡健康检查更加保守。

例如，创建一个查找端口 80 响应的健康检查，该检查可以容许某些失败操作，然后才会将虚拟机标记为 UNHEALTHY，导致其被重新创建。在本示例中，如果虚拟机成功返回一次，则会被标记为“运行状况良好”。如果连续 3 次未能成功返回，则虚拟机会被标记为“运行状况不佳”。以下请求会创建一个全球健康检查。
```
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks

{
 "name": "example-check",
 "type": "http",
 "port": 80,
 "checkIntervalSec": 30,
 "healthyThreshold": 1,
 "timeoutSec": 10,
 "unhealthyThreshold": 3
}
```
注意：请使用支持 HTTP、HTTPS、TCP 和 SSL (TLS) 协议的新版健康检查。旧版 Compute Engine HTTP/HTTPS 健康检查继续有效。
创建防火墙规则以允许健康检查探测连接到您的应用。

注意：如果健康检查探测被防火墙规则阻止，则会因无法连接到应用而将您的虚拟机标记为 UNHEALTHY。在这种情况下，健康状况可能良好的虚拟机也会被自动重新创建。
健康检查探测请求来自 130.211.0.0/22 和 35.191.0.0/16 范围内的地址，因此请确保您的防火墙规则允许健康检查进行连接。在此示例中，MIG 使用的是 default 网络，并且其虚拟机监听的是端口 80。如果端口 80 尚未在默认网络中打开，请创建防火墙规则。
```
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "allow-health-check",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default",
 "sourceRanges": [
  "130.211.0.0/22",
  "35.191.0.0/16"
 ],
 "allowed": [
  {
   "ports": [
    "80"
   ],
   "IPProtocol": "tcp"
  }
 ]
}
```
请将 PROJECT_ID 替换为您的项目 ID。

在 MIG 中配置自动修复政策

在 MIG 中，只能设置一项自动修复政策来应用健康检查。

可以在 MIG 中将区域级或全球健康检查用于自动修复。区域级健康检查可减少跨区域依赖项并帮助实现数据驻留。如果要对多个区域中的 MIG 使用相同的健康检查，则全球健康检查会很方便。

在配置自动修复政策之前，请先做好以下准备：

如果您还没有健康检查，请创建健康检查。
如果您希望在设置新的健康检查时防止错误触发自动修复，则必须先在 MIG 中关闭修复，然后配置自动修复政策。

执行此任务所需的权限

您必须拥有以下权限才能执行此任务：

针对 MIG 的 compute.instanceGroupManagers.update 权限。

这些权限是以下预配置角色中的可用权限。

compute.instanceAdmin.v1（用于在 MIG 中创建和更新自动修复政策）。

控制台

在 Google Cloud 控制台中，转到实例组页面。

转到“实例组”
在列表的名称列下方，点击要在其中应用健康检查的 MIG 的名称。
点击修改以修改此 MIG。
在虚拟机实例生命周期部分的自动修复下，选择全球或区域性健康检查。
更改或保留初始延迟时间设置。

初始延迟时间是新虚拟机初始化并运行其启动脚本所需的秒数。在虚拟机的初始延迟时间段内，MIG 会忽略失败的健康检查，因为虚拟机可能处于启动过程中。这可以防止 MIG 过早地重新创建虚拟机。如果健康检查在初始延迟期间收到健康状况良好响应，则表示启动过程已完成且虚拟机已准备就绪。初始延迟计时器从虚拟机的 currentAction 字段更改为 VERIFYING 时开始计时。初始延迟时间的值必须介于 0 到 3600 秒之间。在控制台中，默认值为 300 秒。
点击保存以应用所做的更改。

gcloud

如需在现有 MIG 中配置自动修复政策，请使用 update 命令。

例如，使用以下命令在现有的可用区级 MIG 中配置自动修复政策：

gcloud compute instance-groups managed update MIG_NAME \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

如需在创建 MIG 时配置自动修复政策，请使用 create 命令。

例如，在创建可用区级 MIG 时，您可以使用以下命令配置自动修复政策：

gcloud compute instance-groups managed create MIG_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE_URL \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

替换以下内容：

MIG_NAME：您要在其中设置自动修复功能的 MIG 的名称。
SIZE：该组中的虚拟机数量。
INSTANCE_TEMPLATE_URL：您要用于在实例组中创建虚拟机的实例模板的部分网址。例如：
- 区域级实例模板：projects/example-project/regions/us-central1/instanceTemplates/example-template。
- 全球实例模板：projects/example-project/global/instanceTemplates/example-template。
HEALTH_CHECK_URL：您要为自动修复设置的健康检查的部分网址。如果您想使用区域级健康检查，则必须提供区域级健康检查的部分网址。例如：
- 区域级健康检查：projects/example-project/regions/us-central1/healthChecks/example-health-check
- 全局健康检查：projects/example-project/global/healthChecks/example-health-check。
INITIAL_DELAY：新虚拟机初始化并运行其启动脚本所需的秒数。在虚拟机的初始延迟时间段内，MIG 会忽略失败的健康检查，因为虚拟机可能处于启动过程中。这可以防止 MIG 过早地重新创建虚拟机。如果健康检查在初始延迟期间收到健康状况良好响应，则表示启动过程已完成且虚拟机已准备就绪。初始延迟计时器从虚拟机的 currentAction 字段变为 VERIFYING 时开始计时。初始延迟时间的值必须介于 0 到 3600 秒之间。默认值为 0。
ZONE：该 MIG 所在的可用区。对于区域级 MIG，请使用 --region 标志。

Terraform

如需在 MIG 中配置自动修复政策，请使用 auto_healing_policies 代码块。

以下示例在可用区级 MIG 中配置自动修复政策。如需详细了解示例中使用的资源，请参阅 google_compute_instance_group_manager。对于区域级 MIG，请使用 google_compute_region_instance_group_manager 资源。

resource "google_compute_instance_group_manager" "default" {
  name               = "igm-with-hc"
  base_instance_name = "test"
  target_size        = 3
  zone               = "us-central1-f"
  version {
    instance_template = google_compute_instance_template.default.id
    name              = "primary"
  }
  auto_healing_policies {
    health_check      = google_compute_http_health_check.default.id
    initial_delay_sec = 30
  }
}

如需了解如何应用或移除 Terraform 配置，请参阅基本 Terraform 命令。

REST

如需在现有 MIG 中配置自动修复政策，请使用 patch 方法，如下所示：

对于可用区级 MIG，请使用 instanceGroupManager.patch 方法。
对于区域级 MIG，请使用 regionInstanceGroupManager.patch 方法。

例如，进行以下调用，以在现有可用区级 MIG 中设置自动修复：

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

{
  "autoHealingPolicies": [
  {
    "healthCheck": "HEALTH_CHECK_URL",
    "initialDelaySec": INITIAL_DELAY
  }
  ]
}

如需在创建 MIG 时配置自动修复政策，请使用 insert 方法，如下所示：

对于可用区级 MIG，请使用 instanceGroupManager.insert 方法。
对于区域级 MIG，请使用 regionInstanceGroupManager.insert 方法。

例如，在创建可用区级 MIG 时，进行以下调用以配置自动修复政策：

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers

{
  "name": "MIG_NAME",
  "targetSize": SIZE,
  "instanceTemplate": "INSTANCE_TEMPLATE_URL"
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
}

替换以下内容：

PROJECT_ID：您的项目 ID。
MIG_NAME：您要在其中设置自动修复功能的 MIG 的名称。
SIZE：该组中的虚拟机数量。
INSTANCE_TEMPLATE_URL：您要用于在实例组中创建虚拟机的实例模板的部分网址。例如：
- 区域级实例模板：projects/example-project/regions/us-central1/instanceTemplates/example-template。
- 全球实例模板：projects/example-project/global/instanceTemplates/example-template。
HEALTH_CHECK_URL：您要为自动修复设置的健康检查的部分网址。例如：
- 区域级健康检查：projects/example-project/regions/us-central1/healthChecks/example-health-check
- 全局健康检查：projects/example-project/global/healthChecks/example-health-check。
INITIAL_DELAY：新虚拟机初始化并运行其启动脚本所需的秒数。在虚拟机的初始延迟时间段内，MIG 会忽略失败的健康检查，因为虚拟机可能处于启动过程中。这可以防止 MIG 过早地重新创建虚拟机。如果健康检查在初始延迟期间收到健康状况良好响应，则表示启动过程已完成且虚拟机已准备就绪。初始延迟计时器从虚拟机的 currentAction 字段变为 VERIFYING 时开始计时。初始延迟时间的值必须介于 0 到 3600 秒之间。默认值为 0。
ZONE：该 MIG 所在的可用区。对于区域级 MIG，请在网址中使用 regions/REGION。

自动修复设置完成后，可能要等待 10 分钟才能开始监控实例组中的虚拟机。监控开始后，Compute Engine 会开始根据您的自动修复配置将虚拟机标记为健康状况良好（否则重新创建虚拟机）。例如，如果您配置的初始延迟时间为 5 分钟，健康检查间隔为 1 分钟，并且健康状况阈值为 1 次检查，时间安排会如下所述：

自动修复开始监控实例组中的虚拟机之前 10 分钟的延迟时间
+ 5 分钟（配置的初始延迟时间）
+ 1 分钟的检查间隔 * 运行状况阈值（60 秒 * 1）
= 将该虚拟机标记为“健康状况良好”或重新创建虚拟机之前，要等待 16 分钟

如果您在配置自动修复政策之前在 MIG 中停用了修复，则可以监控虚拟机健康状况以确认健康检查是否按预期工作，然后将 MIG 重新设置为修复虚拟机。

使用健康检查但不使用自动修复

通过在 MIG 中关闭修复，您可以在 MIG 中使用已配置的健康检查，而不使用自动修复。如果您只想使用健康检查来监控应用健康状况，或者希望根据健康检查实现您自己的修复逻辑，这样做非常有用。

如需将 MIG 重新设置为修复健康状况不佳的虚拟机，请参阅设置 MIG 以修复发生故障和健康状况不佳的虚拟机。

移除健康检查

您可以移除在自动修复政策中配置的健康检查，如下所示：

控制台

在 Google Cloud 控制台中，转到实例组页面。

转到“实例组”
1. 点击要从中移除健康检查的 MIG 的名称。
2. 点击修改以修改此 MIG。
3. 在虚拟机实例生命周期部分的自动修复下，选择不检查健康状况。
4. 点击保存以应用更改。

gcloud

如需移除自动修复政策中的健康检查配置，请在 update 命令中使用 --clear-autohealing 标志，如下所示：

gcloud compute instance-groups managed update MIG_NAME \
    --clear-autohealing

将 MIG_NAME 替换为 MIG 的名称。

REST

如需移除自动修复政策中的健康检查配置，请将自动修复政策设置为空值。

对于可用区级 MIG，请使用 instanceGroupManagers.patch 方法
对于区域级 MIG，请使用 regionInstanceGroupManagers.patch 方法

例如，如需移除可用区级 MIG 中的健康检查，请发出以下请求：

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

{
  "autoHealingPolicies": [
    {}
  ]
}

替换以下内容：

PROJECT_ID：您的项目 ID。
MIG_NAME：您要在其中设置自动修复功能的 MIG 的名称。
ZONE：该 MIG 所在的可用区。对于区域级 MIG，请使用 regions/REGION。

查看 MIG 中的自动修复政策

您可以按如下方式查看 MIG 的自动修复政策：

控制台

在 Google Cloud 控制台中，转到实例组页面。

转到“实例组”
点击要查看其自动修复政策的 MIG 的名称。
点击详细信息标签页。
在虚拟机实例生命周期部分中，自动修复字段显示自动修复政策以及在健康政策中配置的初始延迟时间。

gcloud

如需查看 MIG 中的自动修复政策，请使用以下命令：

gcloud compute instance-groups managed describe MIG_NAME \
    --format="(autoHealingPolicies)"

将 MIG_NAME 替换为 MIG 的名称。

以下是输出示例：

autoHealingPolicies:
  healthCheck: https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check
  initialDelaySec: 300

REST

如需查看 MIG 中的自动修复政策，请使用 REST 方法，如下所示：

对于可用区级 MIG，请使用 instanceGroupManagers.get 方法
对于区域级 MIG，请使用 regionInstanceGroupManagers.get 方法

例如，发出以下请求以查看可用区级 MIG 中的自动修复政策：

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

在响应正文中，检查 autoHealingPolicies[] 对象。

以下是示例响应：

{
  ...
  "autoHealingPolicies": [
    {
      "healthCheck": "https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check",
      "initialDelaySec": 300
    }
  ],
  ...
}

替换以下内容：

PROJECT_ID：您的项目 ID。
MIG_NAME：您要在其中设置自动修复功能的 MIG 的名称。
ZONE：该 MIG 所在的可用区。对于区域级 MIG，请使用 regions/REGION。

检查状态

在 MIG 中设置基于应用的健康检查后，您可以通过以下方式验证虚拟机正在运行并且其应用正常响应：

检查虚拟机的健康状况是否良好
检查当前对虚拟机执行的操作
检查 MIG 是否处于稳定状态

检查虚拟机的健康状况是否良好

如果您在 MIG 中配置了基于应用的健康检查，则可以检查每个代管式实例的健康状况。

检查代管实例的运行状况，以便执行以下操作：

识别未自动修复的健康状况不佳的虚拟机。即使虚拟机在以下情况下被诊断为运行状况不佳，也可能无法立即修复：
- 虚拟机仍在启动，并且其初始延迟时间尚未过去。
- 正在修复很大一部分健康状况不佳的实例。MIG 延迟进一步自动修复，以确保实例组持续运行一部分实例。
检测健康检查配置错误。例如，如果实例报告的健康状况为 TIMEOUT，则您可以检测配置错误的防火墙规则或无效的应用健康检查端点。
通过衡量虚拟机转换为 RUNNING 状态的时间点与虚拟机转换为 HEALTHY 运行状况的时间点之间的时长，确定要配置的初始延迟时间值。如需衡量此时间差，您可以轮询 list-instances 方法，也可以观察 instances.insert 操作与收到的第一个运行状况良好信号之间的时间。

使用控制台、gcloud 命令行工具或 REST 查看健康状况。

执行此任务所需的权限

您必须拥有以下权限才能执行此任务：

针对 MIG 的 compute.instanceGroupManagers.get 权限

控制台

在 Google Cloud 控制台中，转到实例组页面。

转到“实例组”。
在列表的名称列下方，点击要检查的 MIG 的名称。随即打开的页面中会显示实例组属性以及其中所含的虚拟机列表。
如果虚拟机健康状况不佳，您可以在健康检查状态列中查看其健康状况。

gcloud

使用 list-instances 子命令。

gcloud compute instance-groups managed list-instances instance-group
NAME              ZONE                  STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE                            VERSION_NAME  LAST_ERROR
igm-with-hc-fvz6  europe-west1          RUNNING  HEALTHY       NONE    my-template
igm-with-hc-gtz3  europe-west1          RUNNING  HEALTHY       NONE    my-template

HEALTH_STATE 列显示每个虚拟机的运行状况。

REST

对于地区级 MIG，请构建一个向 listManagedInstances 方法发出的 POST 请求：

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group/listManagedInstances

对于区域级 MIG，请使用区域级 MIG listManagedInstances 方法：

POST https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group/listManagedInstances

请求会返回类似于如下所示的响应，其中包括每个代管实例的 instanceHealth 字段。

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/example-group-5485",
   "instanceStatus": "RUNNING",
   "currentAction": "NONE",
   "lastAttempt": {
   },
   "id": "6159431761228150698",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/example-template",
   "version": {
    "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/example-template"
   },
   "instanceHealth": [
    {
     "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/http-basic-check",
     "detailedHealthState": "HEALTHY"
    }
   ]
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/example-group-sfdp",
   "instanceStatus": "STOPPING",
   "currentAction": "DELETING",
   "lastAttempt": {
   },
   "id": "6622324799312181783",
   "instanceHealth": [
    {
     "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/http-basic-check",
     "detailedHealthState": "TIMEOUT"
    }
   ]
  }
 ]
}

运行状况

以下虚拟机运行状况可用：

HEALTHY：虚拟机可访问，可以建立与应用健康检查端点的连接，响应符合健康检查定义的要求。
DRAINING：虚拟机正在排空。与虚拟机的现有连接有时间完成，但新连接遭到拒绝。
UNHEALTHY：虚拟机可访问，但不符合健康检查定义的要求。
TIMEOUT：虚拟机无法访问，无法建立与应用健康检查端点的连接，或者虚拟机上的服务器未在指定超时时间内响应。例如，这可能是由配置错误的防火墙规则或虚拟机上的过载服务器应用造成的。
UNKNOWN：健康检查系统不知道虚拟机，或者其健康状况目前未知。有可能需要 10 分钟，才会开始监控 MIG 中的新虚拟机。

新虚拟机将返回 UNHEALTHY 状态，直到其经过健康检查系统的验证。

是否修复某个虚拟机取决于其运行状况：

如果虚拟机的健康状况为 UNHEALTHY 或 TIMEOUT，并且其初始化期限已过，则自动修复服务会立即尝试对虚拟机进行修复。
如果虚拟机的健康状况为 UNKNOWN，则 MIG 不会立即修复它。这是为了防止对健康检查信号暂时不可用的虚拟机进行不必要的修复。

如果出现以下情况，自动修复尝试可能会延迟：

连续多次修复后，虚拟机的运行状况仍然不佳。
实例组中存在很大一部分运行状况不佳的虚拟机。

我们希望了解您有关虚拟机运行状况值的使用场景、挑战或反馈。您可以通过 mig-discuss@google.com 向我们的团队提供您的反馈。

检查当前对虚拟机执行的操作

如果 MIG 正在创建虚拟机实例，MIG 会将该实例的只读 currentAction 字段设置为 CREATING。如果实例组附加了自动修复政策，虚拟机创建完成并运行后，MIG 会将实例的当前操作设置为 VERIFYING，并且健康检查程序将开始探测该虚拟机的应用。如果应用在其启动过程中通过了此初始健康检查，则虚拟机将通过验证，MIG 会将虚拟机的 currentAction 字段更改为 NONE。

如需检查当前对虚拟机执行的操作，请参阅查看当前对虚拟机执行的操作。

检查 MIG 是否处于稳定状态

在组级别，Compute Engine 会填充一个名为 status 的只读字段，该字段包含 isStable 标志。

如果组中的所有虚拟机正在运行且运行状况良好（即每个托管式实例的 currentAction 字段都设置为 NONE），则 MIG 将将 status.isStable 字段设置为 true。请注意，MIG 的稳定性取决于自动修复政策之外的实例组配置；举例来说，如果您的实例组采用自动扩缩机制，并且正在缩容或扩容，那么由于自动扩缩器操作的关系，MIG 会将 status.isStable 字段设置为 false。

如需检查 MIG 的 status.isStable 字段的值，请参阅检查 MIG 是否处于稳定状态。

查看历史自动修复操作

您可以使用 gcloud CLI 或 REST 查看过去的自动修复事件。

gcloud

将 gcloud compute operations list 命令和过滤条件搭配使用可以仅查看项目中自动修复的相应修复事件。

gcloud compute operations list --filter='operationType~compute.instances.repair.*'

如需详细了解特定修复操作，请使用 describe 命令。例如：

gcloud compute operations describe repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5 --zone us-east1-b

REST

对于区域级 MIG，请向 regionOperations 资源提交 GET 请求并添加一个过滤条件，以将输出列表范围限定为 compute.instances.repair.* 事件。

GET https://compute.googleapis.com/compute/v1/projects/project-id/region/region/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

对于可用区级 MIG，请使用 zoneOperations 资源。

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

如需详细了解特定修复操作，请针对该特定操作提交 GET 请求。例如：

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations/repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5

良好的自动修复健康检查需要具备哪些特点

自动修复健康检查应该比较保守，以免在不必要时删除并重新创建实例。如果为自动修复功能设置的健康检查过于严格，则自动修复程序可能会将繁忙的实例误认为故障实例，并且不必要地重启它们，从而降低可用性。

unhealthy-threshold。此值应大于 1。最好将此值设置为 3 或更大。这样可以防止在发生网络数据包丢失等罕见故障时误判。
healthy-threshold。对于大多数应用来说，将此值设置为 2 就足够了。
timeout。请将此时间值设置为一个较大的值（预期响应时间的五倍或更长时间）。这样可以防止在出现意外延迟（例如实例繁忙或网络拥堵造成的延迟）时误判。
check-interval。此值应介于 1 秒到超时的两倍之间（不要太长，也不要太短）。如果设置的时间太长，就不能及时发现故障实例。如果设置的时间太短，实例和网络可能会因健康检查每秒发送大量探测而变得非常繁忙。

设置基于应用的健康检查和自动修复

准备工作

Console

gcloud

Terraform

REST

价格

设置基于应用的健康检查和自动修复

创建健康检查

执行此任务所需的权限

控制台

gcloud

Terraform

REST

在 MIG 中配置自动修复政策

执行此任务所需的权限

控制台

gcloud

Terraform

REST

使用健康检查但不使用自动修复

移除健康检查

控制台

gcloud

REST

查看 MIG 中的自动修复政策

控制台

gcloud

REST

检查状态

检查虚拟机的健康状况是否良好

执行此任务所需的权限

控制台

gcloud

REST

运行状况

检查当前对虚拟机执行的操作

检查 MIG 是否处于稳定状态

查看历史自动修复操作

gcloud

REST

良好的自动修复健康检查需要具备哪些特点

后续步骤